上一篇寫到，做了五年外賣 PM，我以前很習慣想：

怎麼讓 User 少走一步

但真的試過小美外賣助手之後，我開始覺得 Agent 帶來的是另一個問題：

這一步，為什麼還需要 User 自己走？

如果 User 不再需要一步一步操作，新的問題就來了：

System 怎麼知道 User 到底想做什麼？
例如 User 只說一句：

「幫我點 XX 門市的冰美式，自取。」

對人來說非常好懂。

但對 System 來說，真正需要的可能是：

Intent = Order
Store = XX
Product = Americano
Temperature = Iced
Fulfillment = Pickup
Size = ?
Pickup Time = ?
Payment Method = ?

這也是 AI Native Product 很容易被忽略的一件事：

User 可以開始講人話，但 System 最後還是需要結構。

Form 其實一直在幫 System「翻譯」

以前做產品時，我不太會特別想這件事，因為我們太習慣 Form 了。

例如訂機票，User 要填：

• 出發地
• 目的地
• 出發日期
• 回程日期
• 人數
• 艙等

填完之後，System 就得到一組乾淨的 Structured Data。

User 的需求
    ↓
User 理解 Form
    ↓
User 填入 Structured Data
    ↓
System 執行

所以 Form 不只是一種 UI。

它其實要求 User 做了一件事：

把自己的需求，翻譯成 System 看得懂的格式。

System 需要 Destination，User 就選城市；需要 Departure Date，User 就選日期；需要 Passenger Count，User 就填人數。

過去 PM 會花很多時間設計欄位順序、Required Field、Dropdown、Default Value、Validation。

但底層邏輯一直沒變：

System 定義 Structure，User 負責填進去。

AI 改變的，是誰負責理解這個 Structure

如果今天 User 不填機票搜尋 Form，而是直接說：

「10 月想帶小孩去東京玩五天，從高雄出發，時間可以前後一天不要紅眼班機。
User完全沒有按照 System 的 Schema 說話。

但裡面其實已經包含很多資訊：

Origin = Kaohsiung
Destination = Tokyo
Duration = 5 days
Date = October
Flexibility = ±1 day
Traveler = Adult + Child
Preference = No red-eye flight

AI 做的事情，就是先理解 User 的 Intent，再把 Natural Language 轉成 System 能理解的資料。

所以我現在不太會把 AI Native 理解成：

「以後不用 Form 了。」

更準確的說法反而是：

Form 從 User 面前，搬到了 AI 後面。

Structure 還是在。

只是 User 不一定需要親自理解它。

但 User 通常不會一次把所有資訊說完

再回到剛剛那句：

「幫我點 XX 門市的冰美式，自取。」

AI 已經理解：

Intent = Order
Store = XX
Product = Americano
Temperature = Iced
Fulfillment = Pickup

但 System 真正下單可能還需要：

Store ID
Product ID
SKU ID
Size
Pickup Time
Payment Method
User ID

這時候 Context 就變得很重要。

User 已經登入 App，User ID 不需要再問。

過去十次都喝大杯冰美式，Size 也許可以從 History / Preference 取得。

現在的位置附近只有一家符合的 XX 門市，也可能直接 Mapping 到 Store ID。

所以 AI Product 的流程不是：

User 說一句話
→ AI 神奇地知道所有事情

而更像是：

User 說出 Goal
      ↓
理解 Intent
      ↓
取得 Context
      ↓
補齊 Structured Data
      ↓
準備執行

這也是 AI 相較於傳統 Form 很有意思的地方。

以前缺一個欄位，Form 就要求 User 填。

現在則可以先問：

這個資訊真的需要 User 提供嗎？還是 System 本來就知道？

聽懂 User，還不代表真的能完成 Task

就算 AI 已經知道 User 要買什麼，如果最後只回答：

「好的，你想在 XX 門市買一杯冰美式自取。」

那它其實只做到 Understand。

要真的完成 Task，還要接上 System 原本的能力：

Search Store
    ↓
Get Menu
    ↓
Check Availability
    ↓
Create Cart
    ↓
Apply Promotion
    ↓
Create Order

也就是 Action。

這也是我覺得 Chatbot 和 Agent 很關鍵的差異之一。

AI 不只是理解：

User 想做什麼？

還要能把理解後的結果，交給真正可以執行的 System。

所以完整流程其實是：

Intent
  ↓
Context
  ↓
Structured Data
  ↓
Action

LLM 可以理解 User 想做什麼，但真正把事情做掉的，還是後面的 System。

那 PM 到底要設計什麼？

以前寫 PRD，我可能很自然地從 Page 開始：

• 有哪些 Field？
• Button 放哪裡？
• 點下去去哪一頁？

但如果今天做 AI Native Product，我會先問幾個不同的問題：

1. User 的 Intent 是什麼？

他真正想完成的 Task 是什麼？

2. System 需要哪些 Structured Data？

即使前台沒有 Form，Backend 還是需要清楚的 Schema。

3. 哪些資訊 User 要說，哪些可以從 Context 取得？

Account、Location、History、Preference，都可能已經存在。

4. 缺少資訊時怎麼辦？

要 Ask、Infer、Use Default，還是不能繼續？

5. 最後要呼叫什麼 Action？

AI 是只回答問題，還是真的要 Search、Create、Update、Submit？

如果這些沒有定義清楚，就算 Chat UI 再漂亮，最後也可能只是一個：

很會聊天，但做不了事的 AI。

Day 03｜從一句人話，到 System 真的可以執行

回頭看整個過程，我現在會把它整理成：

User 說出 Goal
      ↓
理解 Intent
「User 到底想做什麼？」
      ↓
      取得 Context
「有哪些資訊 User 沒說，但 System 已經知道？」
      ↓
轉成 Structured Data
「System 真正需要哪些欄位與參數？」
      ↓
呼叫 Action
「接下來要 Search、Create、Update，還是 Submit？」
      ↓
System Execute

以前很多產品，是 User 自己負責把需求翻譯成 System 看得懂的 Structure。

AI Native Product 開始把這件事反過來：

User 說自己的 Goal，AI 負責理解 Intent、取得 Context，再把需求轉成 System 可以執行的 Structure，最後呼叫 Action。

所以 AI 並沒有讓 Structured Data、Schema、API 消失。

反而是：

User 越不需要理解 Structure，PM 越需要把後面的 Structure 定義清楚。